port(wasm): Resolve __data_end and __heap_base as linker data addresses#2188
Conversation
lapla-cogito
changed the title
__data_end and __heap_base as linker data addresses__data_end and __heap_base as linker data addresses
| data_end: u32, | ||
| ) -> Result<Option<LinkerDefinedDataAddress>> { | ||
| match name { | ||
| b"__data_end" => Ok(Some(LinkerDefinedDataAddress { |
There was a problem hiding this comment.
Similar to previous PRs, the matching on symbol names makes me wary. It feels potentially wasteful and like it ideally shouldn't be necessary. Fine for now, but longer-term it'd be good to consider alternatives.
| .ok_or_else(|| crate::error!("Wasm __heap_base address overflow"))?; | ||
| Ok(Some(LinkerDefinedDataAddress { | ||
| address, | ||
| needs_stack_gap: true, |
There was a problem hiding this comment.
What is it about __heap_base that means it needs stack gap? Could be good to document that here.
There was a problem hiding this comment.
OK, I think I get it. I guess in the ELF parts of our linker, symbols like __heap_base would be attached to the start/end of sections, one of those sections would be the stack and memory addresses would just be computed by adding sizes.
| .ok_or_else(|| crate::error!("Wasm __heap_base address overflow"))?; | ||
| Ok(Some(LinkerDefinedDataAddress { | ||
| address, | ||
| needs_stack_gap: true, |
There was a problem hiding this comment.
OK, I think I get it. I guess in the ELF parts of our linker, symbols like __heap_base would be attached to the start/end of sections, one of those sections would be the stack and memory addresses would just be computed by adding sizes.
2 participants
Clang references these as undefined data symbols with
MEMORY_ADDRrelocations, not as globals. Assign absolute addresses after static data layout (data_end, and data_end plus the reserved stack gap for heap_base) and grow memory when the stack gap is required.Part of #1431